A “server image” is the logical embodiment of a server computer (a/k/a a “server”) that contains all of the programs and data needed to provide one or more services by the server computer to its client computers, typically including (but not limited to) a kernel and operating system, device drivers (that are normally associated with the hardware-related components of the server running the image), application software and data, and configuration settings, including those associated with the network and storage environments surrounding the server. A “workload” is the embodiment of a single server running an image. The image can run on a dedicated physical server, in which case the workload will have direct access to all of the server's available resources. Or the image can run on a virtual server provided by a hypervisor host (e.g., VMware ESX or Citrix XenServer) or public cloud infrastructure (e.g., Amazon EC2, Rackspace), in which case the hypervisor or cloud infrastructure regulates access to a pool of resources that are shared between all its virtual servers.
Many computer servers are now being provided in “hybrid cloud environments.” A hybrid cloud environment is a combination of computer servers provided in private data centers and in public clouds such as provided by Amazon EC2, Rackspace, and other entities that provide computing services and communications for a wide variety of customers and applications. A hybrid cloud environment offers varied opportunities to implement workloads on servers through selection of computers, computing services, data storage, application hosting, localized and remote data centers, and other computing functions.
There are many factors to consider when choosing a server to run a workload including performance, cost, security, robustness of the infrastructure, geographic location, etc. Over time the optimal server for a workload might change due to changes in the workload's life cycle (development, test, production, etc.), the number of clients accessing the workload, the availability of more efficient physical resources, or the need to change its geographical location. Over its life time, the total cost of ownership for a workload would be minimized if there were a way to migrate it such that it was always running on the most cost-effective resource that met its current needs.
Migrating a workload from one server to another can be a difficult task, and is more difficult in a hybrid cloud environment. While running on the original source server, the image is configured for the hardware (real or virtual) provided by that server and the network and storage environments surrounding that server. After migration the new server might differ in regard to hardware or environmental configuration such that simply copying the image from the source to the target does not result in a functional workload. United States Patent Application Publication No. US 2013/0290542 “Server Image Migrations into Public and Private Cloud Infrastructures” (Charles T. Watt, et. al.) discusses the issues associated with server image migration and discloses methods and apparatuses for migrating a single server image between physical, virtual and cloud servers. These methods provide great benefit for applications that can be implemented within a single workload, but they can fail when migrating complex computer applications.
“Complex computer applications,” as the term is used herein, are applications that require multiple computer programs, often on different computers (physical or virtual) that communicate with each other in a networked arrangement (such as a local area network or within a data center) to exchange data and provide services, and sometimes with other, external computers in a broader networked arrangement (such as the Internet). Complex applications are often implemented using multiple workloads, each providing a service that is accessible to the other workloads via a network connection. FIG. 2 shows an example of a typical Internet complex computer application. In the example application, an end user 200 accesses the application using a web browser, which connects to a web server workload (WSW) 204 via a firewall 202. The WSW connects to an application server workload (ASW) 206 to access any application logic. The ASW connects to a database workload (DBW) 208 to store or retrieve any application data. To provide secure isolation of the workloads, the communications between the workloads occur on separate local area networks (LANs), either physical LANs or virtual LANs (VLAN). The connection between the end user and the firewall occurs over the Internet 201. The connection between the firewall and the WSW occurs over LAN 1 203. The connection between the WSW and the ASW occurs over LAN 2 205. And the connection between the ASW and the DBW occurs over LAN 3 207. Either or any of LAN 1, LAN 2, or LAN 3 could be a VLAN. To facilitate routing in this environment, each LAN uses a separate subnet. Thus, the WSW and ASW are each configured with two network addresses—one for each subnet to which the workload connects. Each workload is configured to communicate with peer services using the visible network address of the peer. In the example, the WSW 204 accesses the ASW 206 by connecting to IP address 10.1.1.20.
When migrating one or more workloads of a complex application onto new resources, it is often not possible to replicate the original VLANs, subnets, and addresses in the new environment. For example, the cloud servers provided by many public cloud vendors come with just a single network interface and a single network address that is arbitrarily specified by the vendor based upon the specific internal details of the cloud's infrastructure. After migrating one or more servers into such an environment, the complex application will no longer function because the individual workloads will still be configured for the original network addresses. This problem is illustrated in FIG. 3, where the WSW 204 has been migrated into a new environment. Its network interfaces are now on LANs 101 302 and 102 303. If the WSW keeps its original network addresses, there will be no way to route connections back to its original LAN 1 203 and LAN 2 205. To restore the application, the WSW will need to be reconfigured to use new IP addresses that work on its new subnets, and it will need its routing set to access LANs 1 and 2. Even though they haven't moved, the firewall and AWS will also need to be reconfigured in order to access the WSW using its new addresses, and might need to add route table entries pointing to LANs 101 and 102.
In practice, the number of workloads comprising a complex application can be quite large. The task of reconfiguring all the workloads after migration can be quite time consuming and expensive, and sometimes even impossible if the relevant knowledge is no longer available on how to reconfigure the application. Worse yet, the full set of workloads comprising the application might not be known. Many common services such as authentication, directory, and file storage are often not associated with an application because they are shared with other applications and considered common infrastructure. But if the complex application is migrated into another environment that does not have access to these ancillary services, it will not function correctly.
An “overlay network” uses software that sits on top of a shared network infrastructure to transparently link portions of that shared infrastructure into an isolated, secure, functional LAN. An overlay network is a computer network that is a separate network entity, either physical or virtual, built “on top” of another network, such as the Internet. For example, a company's virtual private network (VPN), which has nodes within multiple physical facilities connected by a public network such as the Internet, is a form of overlay network since users on the VPN are transparently connected to each other. Overlay networks are often used to provide multi-tenant use of a shared network infrastructure. They are also used to extend a LAN across multiple network infrastructures.
FIG. 4A shows how an exemplary overlay network 310 can be used with the example application to keep the WSW connected to its original LANs after migration. FIG. 4A adds two virtual network appliances (VNA), VNA 1 401 and VNA 2 402, to FIG. 3. The appliances are linked via a layer 3 network connection or tunnel 305 that they use to tunnel layer 2 traffic between them. Each appliance (VNA) acts like a network switch within its environment, passing traffic between the tunnel and its local LAN to create an overlay network 310 linking the migrated WSW 204 back into LANs 1 and 2 such that it can retain its original network addresses. The overlay network 310 is completely transparent to the workloads and the other network components. To the complex application it appears as if nothing has changed and the WSW 204 is still directly connected to LANs 1 and 2. Thus, the complex application continues to function without modification to the application itself, any of the individual workloads, their operational environments, or user access procedures.
Further details about aspects of the exemplary overlay network 310 and operations thereof can be found below in connection with the discussion of FIG. 4B.
For the foregoing and other reasons, it is difficult and time-consuming to migrate such complex applications within data centers and public cloud data centers, even for skilled computer and information technology (IT) workers. What is needed is a solution that creates a hybrid cloud environment out of the physical, virtual, and cloud servers and associated network resources in a plurality of private data centers and a plurality of public cloud data centers, and allows efficient migration of complex applications to different computing resources within the hybrid cloud environment as new and better computing resources are brought to market.